For purposes of this disclosure, to “reactivate” a data processing system is to turn on or reset the data processing system. Typically, when a data processing system is reactivated, it must complete a boot process before it is useful to a user. For instance, the boot process may include operations such as determining what types of hardware components are present and loading an operating system (OS). The objects that are loaded and/or executed in the boot process may be referred to as “boot objects.” Also, the boot process may include different stages, such as a “pre-boot phase” and an “OS boot phase.” For purposes of this disclosure, the pre-boot phase includes all of the operations executed by the data processing system starting with the first operation after reactivation and ending with transfer of control to an OS boot loader or the like. Accordingly, the OS boot phase starts when control is transferred to the OS boot loader. The pre-boot phase is typically managed by a basic input/output system (BIOS). The BIOS may also be referred to as “firmware.”
In recent years, malware (e.g., computer viruses and rootkits) has been developed to attack low-level code, such as the OS kernel, the OS boot loader, or even the firmware. This type of malicious code may be difficult for anti-virus software to detect and remove, because it may operate at the same security level as the anti-virus software.
The Trusted Computing Group (TCG) has developed standards for trusted platform modules (TPMs) to help protect against such attacks. For instance, the TCG has published a document entitled “TCG PC Client Specific TPM Interface Specification (TIS),” Version 1.21, Revision 1.00, Apr. 28, 2011 (the “TPM Client Specification”). As explained in the TPM Client Specification, a TPM may provide for the secure generation of and storage of cryptographic keys. A TPM may also provide platform configuration registers (PCRs) for safely storing information about the current platform configuration. A TPM may also provide a cryptographic hash generator or “hash engine.” A hash engine may be implemented in hardware, software, or a combination of hardware and software.
A trusted boot process may involve checking the integrity of a system object (or objects) that will be loaded prior to its (or their) loading. For instance, a system object may be run through the TPM's hash engine to generate a hash value for that object. The original object may be referred to as the “message,” and the resulting hash value may be referred to as the “hash result,” the “hash,” or the “digest.” Also, the process of hashing a message may be referred to as “measuring” the message, and the resulting digest may be referred to as the “measurement.” A given object can be verified as not having been altered, relative to an original version of that object, by hashing the given version of the object and then comparing the resulting digest with a digest that is known to have been produced from the original version of the object. Consequently, the integrity of a computing platform can be trusted if digests for all of the loaded objects can be verified against known good digests, provided that the function (or functions) that is responsible for performing that verification can also be trusted. One way to verify a digest is through direct comparison against a list of known good digests for known good messages (i.e., through use of a “whitelist”). Another way is to report the digest to a third party that is trusted to determine and attest to whether or not the digest is good (i.e., through “attestation”). A data processing system that uses a whitelist for digest authentication may be said to perform a “secure boot” or “secure launch.” A data processing system that uses attestation for digest authentication may be said to perform a “measured boot” or “measured launch.” The term “trusted boot” covers both “secure boot” and “measured boot.”
In a trusted boot process, the BIOS of the data processing system may use a TPM to establish a chain of trust which involves a basic function (or set of functions) that is trusted implicitly. That basic function may be referred to as the “root of trust.” For instance, one of the initial functions to be executed by the BIOS upon boot of a data processing system may be a function for measuring and verifying the BIOS itself. That function may be referred to as the “static core root of trust for measurement” (SCRTM). For instance, the SCRTM may be code that is supplied by the platform manufacturer, as a subset of platform firmware that initializes and configures platform components.
In addition, once a hash value has been generated, it may be added to a PCR in the TPM. This process is known as “extending” the PCR. As explained in the TPM Client Specification, different PCRs may be used to store measurements for different types of boot objects. And the TPM may preserve the values in at least some of its PCRs during the life of a computing platform session, but then all PCRs may be initialized to a fixed value (e.g., 0) when the computer platform restarts or resets.
The TCG has also published standards for enhancing the security of storage devices such as hard disk drives. For example, the TCG has published a document entitled “TCG Storage: Security Subsystem Class: Opal,” Specification Version 1.00, Revision 3.00, Feb. 4, 2010 (the “Opal Specification”). The stated purpose of the Opal Specification is as follows: “The Storage Workgroup specifications provide a comprehensive architecture for putting Storage Devices under policy control as determined by the trusted platform host, the capabilities of the Storage Device to conform with the policies of the trusted platform, and the lifecycle state of the Storage Device as a Trusted Peripheral.”
As described in greater detail below, the present disclosure introduces techniques for optimizing trusted boot performance, using secure storage.